1. Field of the Invention
The present invention is generally related to computer based file service extension systems and, in particular, to an extension system for at least multi-tasking computer systems where a secure, block oriented file service mechanism is employed transparently within the function of the operating system.
2. Description of the Related Art
As communal access to and use of computer systems increases, there is an increased demand for control over access rights to and transformation of computer data on an individualized basis. Computer systems are continuing to evolve toward and in the nature of multi-user systems, both directly and indirectly through a heterogeneous architecture of single-user, single-user multi-tasking and multi-user inter-networked systems possessing a remote file sharing capability. Thus, there is increased access capability to computer data maintained in a common logical file system. Furthermore, the file state and transformation requirements of varying data formats increases with the potentially greater number of users and application programs that may access the computer data files.
Conventional operating system based file access and protection mechanisms typically depend on file attribute and access list controls. These mechanisms are, however, inadequate to provide a sufficient level and transparency of security and control. In brief, attribute based controls are typically used to define read, write and execute permissions exercisable by the user, or file owner, a user group, or other, meaning all. Access list controls rely on the existence and maintenance of a predefined list of users that have been granted access rights to a file. Unfortunately, at least the system administrator, or super user, and the access list administrator are not preclusively bound by these permission restrictions. Therefore, access to the data content of a file is not secure against the super user or others who may inappropriately have or gain super user status. An error in the use or function of an application program that modifies the file attributes or control list also results in a security failure.
Conventional file protection mechanisms, incorporated within broader functioning application programs, generally provide for the encryption of the entire data file. These dedicated protection mechanisms are completely independent of file attribute and access list controls. There are, however, a number of drawbacks to the use of such application based protection mechanisms. Each such application program must entirely implement a proprietary protection methodology, such as encryption to ensure the security of the data files specifically associated with the program. Consequently, there is a nearly universal data incompatibility between such programs thereby precluding use or even simple access to common data by different applications.
Use of a dedicated encryption program otherwise independent of any suite of broad function application programs, i.e., an encryption utility program, solves the data file incompatibility problem. However, such encryption programs must generally be executed separately from and prior to the execution of other application programs. Execution also typically results in the restoration of a complete unencrypted data file within the logical file system. Aside from the practical difficulties of dealing with encrypted and decrypted versions of the same data file presumably closely co-resident within the logical file system, the unencrypted data file is no more secure than potentially obtained by conventional reliance on the file attribute and access control mechanisms previously described. Typically, the management of file attribute and access controls is sufficiently tedious, particularly when considered in combination with the separate need to execute and manage the encryption/decryption steps separate from the execution of other application programs, that these additional controls are not implemented. Consequently, the decrypted data file obtained by use of an encryption utility program represents a potentially greater security exposure.
Automatic or transparent file security systems have been proposed, such as the one disclosed in U.S. Pat. No. 5,007,082, issued to Cummins, on Apr. 9, 1991. There, an encryption mechanism is implemented through the addition of a hardware specific software based control routine at the basic input/output (I/O) system (BIOS) level of an operating system. This routine provides for the simple selective re-vectoring of the lowest level file transfer BIOS functions, specifically the floppy diskette access operations, through a file encryption routine. The entire file is automatically encrypted or decrypted when written or read from the diskette. In addition, a global "decryption flag," is stored uniquely in the computer memory and not with the diskette files. This flag is utilized to specify whether a specific diskette is to be treated as an encrypted or ordinary data file store quite independent of the specific files stored on the diskette. Where data is to be transferred to or from an encrypted diskette store, the data is encrypted within the memory of the computer system at the lowest level of the operating system and then only for the duration of the actual data transfer. Cummins specifically teaches that all in-memory data buffers need to store the data file in an unencrypted state in order to ensure operational compatibility with all potentially executing application programs.
A number of obvious vulnerabilities to the secure function of the Cummins mechanism exist. The revectoring approach is vulnerable to simple restoration of the original vectors, thereby bypassing the encryption control routine. Unencrypted diskette data files can then be freely prepared.
The use of a global flag signifying continuing use of the encryption control routine also provides a single, simple point for disabling the function of the encryption routine. Reliance on this flag is not specific to any specific user or file but rather to an entire computer system. Once modified, the security of the entire system is breached irrespective of any specific user or file.
Further, the maintenance of all data buffers within the computer system in an unencrypted state, except briefly in performing a physical data transfer, results in the computer memory image being inherently insecure.
Finally, the Cummins system is described solely with respect to diskette based data file protection. The data protection mechanism provides protection for data files only if removed from a computer system on transportable media. The disclosed mechanism is therefore clearly not applicable to freely internetworked systems, but rather only for physically separate, and physically secured single user systems.
Conventionally, file state and transformation requirements for data files are preserved as an integral part of the data files. As such, the relevant state defining information is largely usable only by the application that created the data file. Other applications must be specifically compatible with another application's file format or provide, typically through execution of a separate program, a conversion between file formats. All of the disadvantages discussed above, related to encryption and multiple instances of a given file, attach here as well.